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ThreePointOh, We Hardly Know Ye 


Th e only way to really learn FileMaker is to wrestle 
into submission a series of cranky real-world prob- | 

lems. The match starts by getting some idea of how 
the features work in the literal, mechanical sense. 

The manual used to be the place to learn features, 
but with 3.0 the on-line help file is a better coach. 

The real struggle is figuring out how basic features 
can be combined, with a certain amount of fiddling, 
into the new derived features required to accom¬ 
plish reasonable usefulness. FileMaker 3.0 presents 
the biggest jump in features ever in a FileMaker 
upgrade. The number of possible derived features is 
dizzying. 

A number of us were sitting around the office 
the other day speculating about what the new File¬ 
Maker could do if pushed. How weird might de¬ 
rived features be? What are the boundaries of the 
3.0 design space? Based on some inspired portal 
menus done by one of our consultants, Bill Richard¬ 
son, it occurred to me that buttons and other seem¬ 
ing layout objects could actually be composed of 
related fields - in short, buttons in a portal. 
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Buttons In a Portal 

Aside from the amusement value, is there any 
reason to do such a thing? We do a lot of consulting 
and sometimes want to reuse files. This may mean 
an entire interface has to be redone to match the 
look and feel of the new project. Very little in life is 
so blindingly tedious. We also have situations where 
some individuals using a central database need 
different layouts. This may be for vision reasons, 
including color blindness, or to deal with different 
monitors or platforms. The usual solution to these 
problems is multiple layouts. Sometimes, entire sets 
of layouts are created to accommodate different 
monitors and color depths: a file with 10 functional¬ 
ly different layouts requires 30 layouts to deal with 3 
different monitors. Also changes to layouts and 
scripts must be done several times and there are a 
host of other complexities which increase costs and 
drive developers to all-nighters fueled with Jolt cola 
and Twinkies. 

We usually offer interface choices to customers 
before a project starts. Like showing a wallpaper 
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sample book, we need a way to show a lot of 
look and feel choices quickly. Also, from time 
to time, customers just want to see somewhat 
different screens, as a change of pace or a 
matter of personal preference (“I hate grey 
screens, I feel ‘pink’ today!”). Presumably 
this is why Apple keeps mentioning that its 
next operating system, Copland, allows indi¬ 
viduals to have custom desktops. Be nice if 
the entire look and feel of a FileMaker data¬ 
base could be customized quickly. 

Buttons in a portal, with some additional 
tricks, promised to allow that magic. I had 
another reason to futz with related buttons. I 
was invited to speak, together with Eric Cul¬ 
ver, at the Claris World Wide Developers 
Conference on the topic “Tips and Tricks”. I 
needed a showcase for some of the interesting 
new features of FM 3.0.1 wanted something 
splashy, something to make the point that we 
are in a new world where old FileMaker con¬ 
cepts are turned inside out in strange and 
interesting ways. 




Figure 1 


Can We Trust Our Eyes? 

Figure 1 shows a main menu. The 
images are buttons for selecting de¬ 
partment sub menus, one of which is 
shown in Figure 2. The sub menus 
use a row of task buttons for moving 
out into the database and performing 
specific functions like entering a new 
customer record. To show the cus¬ 
tomer some different interface op¬ 
tions, the seven sub menus come in 
three flavors, each with a different 
background, button design and color 
scheme (Figures 2, 3 and 4). The 
main menu has no appearance varia¬ 
tions but must be functionally differ¬ 
ent for each set of the three sub menu 
designs. 

In FileMaker before version 3.0 


Figure 2 

grey background, silver buttons, black text and lines 
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Calendar Tool 


put mee or,* sentence button ooesription tier* 


put roe* one sentence button aecsription here 


Samps* 


put roc* on* sentence button decsription her* 


Dat* Er.tr y 


put roe* on* sentence button decsriptlon her* 


put roc*on* sorters;*biiton <jeesriptlon her* 


«■■ there was very little choice about how 

I to do this. While fancy techniques like 
data-driven layouts might allow some 
interesting trickery, the screens 
shown here required multiple lay¬ 
outs. Three functionally different 
main menus and three times seven 
sub-menu appearance variations 
required as many as 24 separate lay¬ 
outs, depending on developer experi¬ 
ence and ingenuity. 

FileMaker 3.0 allows all the menus 
to be done with a single layout; 24 
virtual layouts are embodied in one. 
More terrifying, nothing on the 
screens is what it appears to be. The 
buttons, background, text and other 
seeming layout objects are not in the 
file on screen at all but are related objects 
which actually live in a support file called 
Resources_. Everything that an experienced 
FileMaker user would immediately know 
about the nature of these menus is profoundly 
wrong. 


Menus.FM3 


Figure 3 

grey and dark grey background, grey and blue buttons, 
white text and lines 


Figure 4 

black and white and grey background, grey buttons, dark 
blue text and lines 


Many-to-One In Another Sense 

Figure 5 shows the area of the 
g||i| layout which generates the main menu. 

Readers with some 3.0 experience will 
notice that none of the objects on the 
vj layout is local to the Menus.FM3 file. 
The field names are preceded by dou¬ 
ble colons indicating that the 
field is in another file and shown here 
„ - through a relation. Of course the 

same is true of the portals which are 
windows showing multiple fields and 
records from another file. Nothing on 
this part of the layout is really “here” 
in the sense of beinv in this file. 


Menus. FM3 


■eakfast: 


About 
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case the Resources_ file) and, through 
relations, using these elements over and 
over again. Whenever we want to change 
an element to something new, changing 
it once in Resources_ makes the change 
universally throughout all the files in our 
database. The simplest case can be seen 
with the company logo field in the up¬ 
per left hand corner of the layout. 

In the first four figures the company 
logo is the “Calendar Tool” label. Ordi¬ 
narily, this is the logo of the organiza¬ 
tion for which the software is prepared 
and shows the appropriate graphic. Figure 
5 shows this field is called gCompany 
Logo. The “g” prefix indicates that the 
field is global field, a new type in 3.0. 
There is no requirement that global 
fields start with “g” but it somehow 


Figure 5 

FileMaker must manage the use of the same 
global field for different values from more 
than one user. The solution is that global 
fields are stored locally for each computer on 
the network. So, interestingly, the gCompany 
Logo field value can be different for each 
machine using a given file. For you, the com¬ 
pany logo can easily become a Dilbert char¬ 
acter if you like. More generally, your entire 
interface can be unique to you if its layouts 
are constructed of global elements. You may 
have a different interface each day of the week, 
for example. 

Figure 6 shows the definition dialog for 
global fields. “Container” is a new field type 
replacing the “Picture” type in previous ver¬ 
sions of FileMaker. 

The relation required to see gCompany 
Logo starts with another global field created 
in the file where you want the logo to appear. 

This file is usually called the “home” file and 
the file where the logo is stored is called the 


became an instantaneous universal con¬ 
vention sometime during the beta testing of 
FileMaker 3.0 and the newsletter uses it. (Per¬ 
haps summary fields should start with “s”.) 

Global fields are extraordinarily useful. A 
value in a global field, though stored only 
once, is available to all records in a file. In this 
case, a single graphic can appear in many 
layouts, and, through relations, in many files. 
So, although technically you might say that a 
FileMaker global field is a file global, relations 
make it in effect an application global. Since 
such a field is available from any FileMaker 
file with the appropriately defined relation, it 
matters very little where its home is. In our 
consulting practice we use Resources_ as a 
common utility file in all our databases so we 
usually put a global company logo field there. 
Where we are fortunate enough to be able to 
use some other files from previous work, all 
company logos can be changed to that of the 
new client instantly. 

Global fields have a subtle quirk. Since 



they are often used in multi-user situations, “foreign” file. These terms are different from 
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Befins* Fields far "Resources- 


72 field(s) 


O ptions 



Figure 6 


those traditionally used in FileMaker lookups 
and the newsletter will adopt them for rela¬ 
tions, including lookups which are now a type 
of relation. The required new global field is 
called the “home key” and we name it gFile- 
Key, a text field. gFileKey requires a corres¬ 
ponding match field in Resources_. This 
match field is the “foreign key” and we name 
it FileKey. For several reasons FileKey is not 
global. The first reason is a requirement of 
FileMaker relations which everyone has to 
learn: a foreign key must be indexed. Global 
fields and calculation fields which use global 
fields are never indexed. Therefore global 
fields cannot be used as, or in, foreign keys. 
This restriction does not apply to home keys. 
FileKey is a text field and, for reasons we shall 
shortly see, a repeating field with ten lines. 

Figure 7 


Define Relationships for u Menus.FM5” 


Relationships provide access to data in other files. 

7 relationship(s) 

RelationshiD Name 

Relationship 

Related File 


* Button Menu 

Menu Titles = ::SubMenuKey 

Resources— 

o 

* File key 

gFileKey = ::FileKey 

Resources- 

♦ Menu Type 

gMenu Type Key = : Jienu Type ... 

Resources- 


* SubMenu Pix 

Menu Titles » : :SubMenu Key 

Resources— 


♦ g Portal Key One 

g Portal Key One = ::Custom Por.. 

Resources- 


♦ g Portal Key Two 

g Portal Key Two = : :Custom Po... 

Resources- 


♦ g Portal Key Three 

g Portal Key Three = : -.Custom B.. 

Resources— 

o 


| [ Edit... | [ Duplicate | [ Delete ] [ Done ) 


We now need to define a relation which 
grabs the gCompany Logo graphic from the 
Resources_ file. A 3.0 relation is similar to 
the non-relational FileMaker lookup in that 
you specify two fields whose values might 
match. These fields are usually in different 
files but for special purposes can be in the 
same file - can even be the same field match¬ 
ing itself. This newsletter has often used simi¬ 
lar “self-lookups” as part of our bag of tricks. 
(The relational self-lookup is called a “self¬ 
join”.) When a match does occur, it is used to 
find and display the field value(s) in the 
matching record(s). 

Figure 7 shows the first part of the Define 
Relationships set up. This window shows all 
the relations defined for this file. Unlike look¬ 
ups, relations are defined separately from the 
fields (and other elements like portals and 
pop-up lists) for which they are used. This 
allows you to define a relation once and use it 
over and over again. Separating the relation 
from the objects it serves can be confusing. 
For this to be helpful rather than a pain the 
relation name is important. Give yourself a 
break and use very descriptive names for 
relations. Claris was thoughtful enough to 
make the relationship setup available not 
only from the File Menu but also from field 
definitions and other places where relations 
are used. This allows you to consider a rela¬ 
tion in the immediate context of its use. Very 
helpful. Typical superior Claris design. 

Double-clicking on the relationship 
name, “File key”, brings up the dialog box 
where the matching fields of the relation are 
selected (see Figure 8). The check box selec¬ 
tions for “When deleting...” and “Allow cre¬ 
ation....” are usually functions for portals and 
are left unchecked for this relation. 

We now require some values in these 
fields for the relation match to happen. In 
this case we have arranged things so that the 
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home key global, gFileKey, contains the 
name of the file in which it lives. This same 
file name is added to the foreign repeating 
field key, Filekey, in Resources_. To insert a 
value in the home key we place the global 
field on a temporary layout, go to Browse 
mode and enter our file name, Menus.FM3. 
This may never need to be done again, de¬ 
pending on how the file is used, so the tem¬ 
porary layout can be deleted. Scripts can also 
be used to set global field values, using the 
“Set Field” step, which we use later in this 
article. 

Figure 9 shows part of a layout (“Prefer¬ 
ences”) in Resources_ where the foreign key 
value can be entered. Once this is done, the 
relation works and the company logo can be 
placed on any layout in Menus.FM3. The 
logo can be changed by putting a new graphic 
in the container field gCompany Logo. For 
this example, the foreign key field (Figure 9) 
need not be repeating. File names for multi¬ 
ple files in a database can easily be put in 
separate records in a non repeating field (ev¬ 
ery record in a file has access to the global 
gCompany Logo field). The home key is 
repeating so we can store non-global graphics 
and other preference values in separate Re- 
sources_ records for finer degrees of cus¬ 
tomization than used in this simple company 
logo case. 

Portals 

The other layout objects in Figure 5 are 
two portals and the fields within them. Por¬ 
tals are view-as-list windows of all related 
records. Or more precisely, a view of selected 
fields in all related records. Like single related 
fields, portals require a defined relation. The 
advantage of a portal is the ability to view all 
related records, not just the first record which 
matches the relation. If many records match, 
the portal can be scrolling so large numbers 


Edit Relationship i 


Relationship Name 


A relationship defines a set of matching related records for 
each record in the current file. 

Match data from field in current file: With da 

Menus.FM3 Resour 


Specify File... 


DagsLateLabel 
Dag sToDoLabel 
Display Day sLate 
Display Day sToDo 
Do Date Calc 
Elapsed Days 
g Portal Key One 
g Portal Key Three 
g Portal Key Two 

| | When deleting a record in this file, also 
delete related records 


With data from field in related file: 

Resources. 

I : Button Title Three 
: Button Description 
: :gMenuPix 
: :Menu Title One 
::Menu Title 
: ;Menu Title Two 

I ::Menu Title Three 
: :MenuPix 
: igCompany Logo 

I I Allow creation of related records 


of records can be seen. Portals have another 
advantage which we do not use here. You can 
create and delete related records through a 
portal. The word portal is a good one. Think 
of a portal a magic tunnel into another file, 
and consider yourself in the related file - not 
in the home file - when viewing or editing 
within its boundaries. 

We require two portals, one for three 
menu buttons on the left and a second portal 
for four buttons on the right. This is a design 
requirement - we wanted it to look this way. 
It is not a technical necessity and all menu 
buttons could appear in a single portal. We 
have two fields in our portal: Custom Button 
Field and Sub Menu Key. There are many 
other fields in the related records of course, 
we are only interested in seeing these two. 

The field and portal boundaries are invisible 
in Figure 5 but both fields are within the por¬ 
tal area. This is critical. If fields or other ob- 


Figure 8 


Figure 9 
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Resources. 


|Preferenc.r| 


Records: 


Found: 


Sorted 


Submenu Key View Order 


Locator 3 


Magic Layout 4 


Meetings 5 


Resources 6 


Solarium 7 


Custom Portal Key 


1 Menus .FM3Main1 


Menus .FM3Main2 


Menus .FM3Main3 


Menus ,FM3Main4 


Menus .FM3MainS 


Menus .FM3Main6 


■ ■ Menus ,FM3Main7 


Figure 10 


jects overlap portal boundaries all hell breaks 
loose and you end up with massively corrupt 
files. The hatched area indicates the full ex¬ 
tent of the portal when the number of rows 
selected is considered: three on the left and 
four on the right in our case. 

Figure 10 is a view-as-list of some of the 
records in Resources_ which contain our 
main menu buttons and graphics titles. The 
numbers are used to assign buttons to one of 
the two portals. Although seven numbers are 
used - representing wishful thinking that 
some day records in portals may be easily 
sorted - only two different numbers are really 
required for this job. 

The two portals each need a relation to 
determine what records from which file ap¬ 
pear inside. In this case, we are looking at the 
same file, Resources^, but selecting two dif¬ 
ferent groups of records. The home fields for 
our two relations are gPortalKeyOne and 
gPortalKeyTwo. Both are global text fields. 


Their values are set and cleared with scripts, 
allowing us make the menus appear and dis¬ 
appear. The “Set Field” script step required is 
new to FileMaker 3.0. Unlike the older 
“Paste” or “Paste Literal” steps, “Set Field” 
does not require that the field in question be 
on the current layout. “Set Field” can also set 
a field value to the result of a calculation. 

Figure 11 shows the “Set Field” calcula¬ 
tion. gFileKey is the same field used for the 
logo relation. It simply contains the name of 
the current file, Menus.FM3. The gMenu 
Type Key field is new to our discussion. It is 
also routinely changed through the “Set Field” 
step. When scripts are run moving us back 
and forth between the Main Menu and the 
seven sub menu screens, this field’s value is 
changed from “Main” to any value between 
“SubmenuOne” and “SubmenuSeven”. So 
the function of gMenu Type Key is to name, 
and through relations determine, which screen 
we see. For present purposes, any value in 
“gMenu Type Key” other than “Main” means 
the relation match for our portals fail and the 
Main Menu disappears. 

When the Main Menu screen appears, 
our two portal home keys have the values: 

g Portal Key One: 

Menus.FM3Main1 

Menus.FM3Main2 

Menus.FM3Main3 

g Portal Key Two: 

Menus.FM3Main4 

Menus.FM3Main5 

Menus.FM3Main6 

Menus.FM3Main7 

These key values match values in some 
records in Resources_ (see Figure 10). With 
a match, two fields from Resources_ appear 
in the portal(s): Custom Button Field (the 
picture) and Sub menu Key (the menu item 
name). The line connecting the picture and 
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the menu item name is a layout graphic (an 
ordinary line). Quite logically, if no portal 
relation match occurs this layout object sim¬ 
ply is not displayed. The relation is consid¬ 
ered a match if any one of the lines in the 
home key (gPortal Key One or gPortal Key 
Two) matches the foreign key (Custom Por¬ 
tal Key, figure 10). A line, of course, is de¬ 
fined by a carriage return (“1”) between 
values and so such a key can be calculated, as 
is ours. 

This small feature of portal keys can be 
used to great advantage. For instance, you 
can copy to the clipboard the values of a field 
in a found set (each record’s value is separat¬ 
ed from the value of the next record by a 


Specif y Calculation 


Current File (" Menus .FM3 ") 

■^1 

* Items 


* Items Uncompleted 

Av Elapsed Sum 

■ 

Av late Sum 

ini 

Blank 

tel 

Calc A End Date 

11 

Calc A Start Date 

Calc B End Date 

w 


®0 


Operators 

View 1 all by name 

- 

= 



Abs (number) 


at 



Atan (number) 


> 



Average (field...) 


< 



Case (test 1, result 1 [, test2, re 


1 



Choose (test, resultO [, resultl, 


S 

'-fO 


Cos (number) 


and 



Count (field...) 

(1 > 

or 

± 


Date (month, day, year) 

& 


gFileKey & gMenu Type Key & "1" & "fl" & 
gFileKey & gMenu Type Key & ,, 2" & "fl" & 
gFileKey & gMenu Type Key & "5" & “fl'l 


Figure 11 

carriage return) and then paste this into a 
portal key field. The records which appear in 
the portal will then be the found set. As we 
see in future articles in this series, this can be 
very handy. 

Part 2 appears in the next issue. 

* J V+ 


mmmmm m mmmmmmsmmmm g mmMmm 

Where Are We? 


-FileMaker 3.0 was available for alpha/beta 
testing for about a year before it was released. 
During most of that time it was difficult to 
use on complex work because it was unstable. 
When released late last year 3.0 still had key 
dysfunctions, especially with repeating fields. 
This newsletter suggested at the first of the 
year that only with the delivery of 3.0 v3 were 
we likely to have a version robust enough to 
handle critical applications. This prediction 
turned out to be accurate. The FileMaker 
Report office converted to 3.0 a few weeks 
after the appearance of 3.0 v3 and we have 
had no problems at all. We could not have 
converted sooner, however, because we use 
repeating fields extensively, often in “undoc¬ 
umented” ways. 

I talked to a subscriber the other day who 
felt burned by problems in the initial File¬ 
Maker 3.0 release. First he had delayed a key 
project for a long time waiting for 3.0, and 


then felt vl and v2 were too buggy. “If we had 
known what we were in for, we would have 
gone with (another database program) two 
years ago.” Interestingly, though, he allowed 
that although he had gotten a lot of heat from 
his boss over delays, he was glad they were 
using FileMaker now rather than being stuck 
with an inferior program. 

I have not been disappointed with 3.0's 
roll out because I anticipated the “real” deliv¬ 
ery schedule. Partly I had access to informa¬ 
tion through various contacts with Claris, 
whose corporate headquarters is just over the 
hill from our offices. More important, I’ve 
been through enough of these major up¬ 
grades to key software to have some idea 
about how long it takes to get these things 
right. 

Claris has done extraordinarily well. For a 
large company they even make consistently 
good policy decisions. I cannot fault their 
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handling of the Windows 3.1 issue for in¬ 
stance. In contrast, of course, consider Micro¬ 
soft and their recent management of Word 
for the Mac. 

So, where are we with 3.0? The FileMaker 
community has had most of a year to start 
figuring out how to use it. We have had a few 
months to try it on the most complex appli¬ 
cations. What have we learned? 

Lesson 1 :Take It Easy 

Most of the arguments for FileMaker’s 
flat file structure are still valid. Flat files are 
much faster to develop, easier to use, and 
require less professional support and main¬ 
tenance. 

We have experimented with various rela¬ 
tional improvements to flat file designs and 
had mixed results. There is no doubt that 
relational FileMaker can do elegant things 
that are impossible in a flat file. For instance, 
we have done some scheduling applications 
with remarkable user convenience features 
never possible before. On the other hand, we 
made an address file relational and found the 
resulting database frustratingly unmanageable. 

Of course, we may have just designed the 
address database badly. Flowever, readers are 
reasonably likely to make some of the same 
mistakes we did and get into the same trou¬ 
bles. Our database tried to take advantage of 
related files for addresses (one record = an 
address) and for phone numbers (one record 
= a phone number), working off a basic per¬ 
son (one record = one person) file. We also 
tried to have a separate company (one record 
= a company) file but soon gave up on that as 
hopelessly complex. The resulting set of files 
is difficult to use and maintain. We still have 
n<3t been able to do an interface to address 
records in a portal which is usable by the 
average office worker. And all aspects of name/ 
address importing and exporting are a night¬ 


mare. Although the experience has been a 
tremendous education in FileMaker’s new 
features, it is not something either the timid 
or impatient want to repeat. 

My tentative conclusion? Make sure what 
you are getting with the move to relationality 
is worth the price. If relational structures do 
not have big payoff potential, hesitate until 
you really understand what you are doing. 
Count on that understanding taking a couple 
of years. Never go from a flat file to a relation¬ 
al design on whimsy. 

Lesson 2:This Is Not Your Mother's FileMaker 

A consultant called me last month to talk 
about bidding a job. She had a rival proposing 
a database in an long-time relational program. 
Based on her extensive pre-3.0 FileMaker 
experience she thought the job could be done 
profitably for about $30,000. Her competitor 
was bidding about $100,000, with lots of 
caveats. Based on experience with a dozen 3.0 
projects, my reaction to her situation was that 
if it is a $100,000 relational project then it is 
probably a $100,000 relational FileMaker 
project as well. Every aspect of the job will 
take longer: more development time, more 
difficult transitions, much more customer 
support and/or idiot-proofing. My guess is 
that the average relational job is at least four 
times the effort of a flat file equivalent. 

While it is likely that FileMaker 3.0’s 
superior design makes it generally a quicker 
development environment than competing 
databases, there are offsetting considerations 
such as a decade’s worth of tools and experi¬ 
ence accumulated around some of the older 
relational products. A fully relational project 
in FileMaker 3.0 probably has to cost about 
the same as a relational project in any other 
database program. This creates some inter¬ 
esting dilemmas for consultants. Corporate 
customers have traditionally been unwilling 
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to pay the same price for FileMaker solutions 
that they paid for “serious” projects in more 
difficult-to-use programs. 

The reality is that when used in a fully 
relational way FileMaker 3.0 is much harder 
to use than flat file FileMaker. If you had 
trouble with repeating fields in FileMaker 2.1, 
you are probably not ready for serious rela¬ 
tional file architectures. If you didn’t do 
much 2.1 scripting, the new script features 
like loops are going to be baffling. 

I have heard some complaints that File¬ 
Maker’s documentation is weak on help us¬ 
ing 3.0’s new features. This situation is not 
going to change much because we are talking 
about a much bigger problem than “What is 
this new feature?” or even “What can I do 
with this new feature?” You now need to 
know “How should or shouldn ’t I use this 
feature?” This is a much bigger problem and I 
have seen no promising suggestions for pro¬ 
viding effective support of nonprofessional 
users. 

Lesson 3: Where To Learn More 

So, how do you get up to speed? The 
preceding article starts to lay a foundation for 
understanding basic 3.0 features. This news¬ 
letter will use this foundation in articles on 
real-world uses of 3.0. Claris has a strong 
series of 3.0 classes, including the best File¬ 
Maker class I ever attended, the second Ad¬ 
vanced class. Claris also has some good 
training material including a nice introduc¬ 
tion called “Going Relational with FileMaker 
Pro”. Of the FileMaker 3.0 books I’ve seen, 
the one by Chris Moyer is (so far) the best. 
Investigate user groups. We have a monthly 
user group meeting in the San Francisco area 
at Claris in Santa Clara. There is a strong 
FileMaker SIG in southern California and 


ones in Chicago, Denver, and, of course, 
Boston and Berkeley. On-line the Blue World 
FileMaker list is terrific, although now in the 
stage of getting too long to keep up with reg¬ 
ularly. 

Is there training to avoid? I still have seri¬ 
ous qualms about the relevance of traditional 
relational theory and techniques. A few rela¬ 
tional concepts, once modified to fit File¬ 
Maker’s unique structure, are terrifically 
helpful. Overall, however, the “it's just anoth¬ 
er relational database” attitude is definitely 
wrong. Further, relational theory proponents 
seem to me dogmatic and overreaching. They 
apparently believe that traditional relational 
approaches are the only way to think about 
databases. Many of these proponents have 
strong software backgrounds and I am loath 
to dismiss the wisdom of long experience and 
many brilliant minds. Still, if their advice is 
followed fully and literally, FileMaker may 
become, through the way it is used, a weak 
version of traditional relational programs. I 
would hate to see FileMaker acquire all the 
disadvantages of older database software 
while losing its unique advantages. 

FileMaker should not become a captive 
of the professional software community. 
Traditionally trained programmers have 
biases which worry me, including a tendency 
to solve all problems with programming 
(FileMaker scripts, Apple Script, or similar 
PC software) rather than with creative archi¬ 
tecture and interface. They also rely too much 
on idiot-proofing rather than user training. 
FileMaker was the first real “end-user” data¬ 
base, a noble if somewhat shaky proposition. 
Some way or another we need to figure out 
how to retain the strengths of old FileMaker 
while effectively using the new more powerful 
features. It ain't gonna be easy. 
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Detecting Out-of-Place Characters in Address Fields 


Evolution of a Useful Equation 
By Joe Kroeger 

The Problem 

I recently accumulated in one file a bunch 
of address records from several disparate 
sources. The addresses had been entered and/ 
or updated over the past couple of years by a 
number of people. Strict supervision was 
often not possible so the operators entered in 
their own way, using a variety of mental and 
physical formats. Some had little FileMaker 
experience; some did not always remember 
the rules; some had only recently graduated 
from typewriters; some were bosses who 
should never have been allowed near a com¬ 
puter; some opted for speed over accuracy. 
Some addresses were entered on different 
computer platforms or into spreadsheets. 
And so forth. The result is that my accumula¬ 
tion of these addresses gathered together lots 
of vagrant characters, especially returns, peri¬ 
ods, and spaces, living in places where they 
should not. 

An extra space here or there does not 
make much difference on a mail label, but 
when searching for duplicate records a space 
in the wrong place is often important. Simi¬ 
larly, an extra period (in abbreviations for 
example) does not ruin a mail label but some¬ 
times interferes with de-dupping efforts. The 
US Postal Service requests no punctuation on 
mail labels and formal (non-label) addresses 
spell out all words. In either case getting rid 
of periods helps. A return character in the 
wrong place (when entered instead of a tab, 
for example) results in a garbled mail label or 
hidden address information or unsuccessful 
searches for duplicates. 


The Context 

My particular situation requires attention 
not only to return characters that can cause 
serious problems, but to extra spaces and 
periods as well. I have over the years put to¬ 
gether a series of equations in my address files 
that help diagnose the health of each record. 
I’ve written in these pages about the value of 
various NameCode calculations for uniquely 
identifying an address, thus aiding searches 
for dups. I look for apostrophes, name field 
entries that are not names of people (like 
“Computer Supply” or “Art Department”), 
missing support data (like serial numbers, 
entry dates, address-type information), and 
spaces within the last name. I have an equa¬ 
tion for each address field that counts the 
number of characters in the field using the 
Length function. There is another calculation 
that adds together all the individual lengths to 
compute an overall address length. These are 
useful (a) for updating a record from an out¬ 
side source (using NameCode and Address 
Length to help assure a match), (b) for de¬ 
tecting changes in an address when compar¬ 
ing two records, and (c) for diagnosing entry 
errors. In my case, extra characters disturb 
the matching/updating process. 

I use individual field length calculations 
to look for very short and very long fields. 

The Street field, for example, should probably 
never be just one or two characters long. I 
once found an Organization name that was 
266 characters long - it turned out that 23 of 
the characters were the name of a corporation 
and 243 were just extra spaces! (Someone 
had probably put some papers on the key¬ 
board and applied just enough pressure to 
the space bar to inadvertently enter a string of 
spaces.) 
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Moving to Solutions 

The Position calculation function is in¬ 
valuable for detecting any character - even 
those not indexed by FileMaker. Returns in a 
field are easily located like this: 

FName Ret = Position (FirstName, "H", 1) 

Any result greater than zero indicates the 
presence of a 11 character (H = return) in the 
FirstName field. You can then Find in the 
FName Ret field for values >0. A click in the 
FirstName field of a suspect record makes it 
obvious where the vagrant return character 
is, allowing it to be removed. 

Spaces can also be detected, but it is 
slightly trickier. There are often spaces in the 
Organization, Street, and City fields that 
should be there. I decided to look for just 
leading and trailing spaces within a field. 
Remembering that in this newsletter the sub¬ 
stitute for a space when writing a calculation 
is the character a, then consider this equation: 

FName Spc = If (Left (FirstName, 1) = " A " or 
Right (FirstName, 1) = "a", 1 , 0) 

(When actually entering any of these equa¬ 


tions in FileMaker, use a space instead of the 
A character shown here.) 

In this case the FName Spc field contains 
either a 1 (if there is a space at either the be¬ 
ginning or the end in the field) or a 0. Thus a 
Find for 1 in the FName Spc field results in a 
set of records that have a FirstName that 
needs fixing. 

Can both returns and spaces be detected 
in one equation? Sure: 

FName RetXSpc = 

If (Position (FirstName, "H", 1) > 0 or 
Left (FirstName, 1) = " A " or 
Right (FirstName, 1) = "a", 1 , 0) 

Can returns and spaces and periods be 
detected in one equation? Try: 

FName Ret\Spc\Per = 

If (Position (FirstName, "H",1) > 0 or 
Left (FirstName, 1) = " A " or 
Right (FirstName, 1 ) = "A" or 
(Position (FirstName,1) > 0,1,0) 

But I didn’t want to have a separate calcu¬ 
lation like this for every address field if I 
could help it. Would it be possible to com- 


Alternate Calculations 

There are almost always different ways to accomplish a given calculation in FileMaker. To 
detect leading and trailing spaces instead of the approach shown above, the Trim function 
also works. Try this: 

FName Spc = If (Length (Trim (FirstName)) < Length (FirstName), 1,0) 

Instead of making a single big If to detect returns and spaces in several fields, a set of nest¬ 
ed If functions also works: 

All RetXSpc = If (Position (FirstName, "H", 1) > 0 or Left (FirstName, 1) = " A " or 
Right (FirstName, 1) = " A ", 1, If (Position (LastName, "1I",1) > 0 or Left (LastName, 1) = " A " or 
Right (LastName, 1) = " A " ( 1, If (Position (JobTitle, "H",1) > Oor Left (JobTitle, 1) = " A " or 
Right (JobTitle, 1) = "A"i, If (Position (Organization, ’TM) > 0 or Left (Organization, 1) = " A " or 
Right (Organization, 1) = " A ", 1, If (Position (Street, "H",1) > 0 or Left (Street, 1) = "a" or 
Right (Street, 1) = " A ", 1,0)))) 
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bine the detection of odd characters that may 
be in any of several fields into one calcula¬ 
tion? I tried it with just returns by extending 
the previous equation style and making one 
big If-and-Or statement: 

All Ret = If (Position (FirstName, "H", 1) > 0 or 
(Position (LastName, "IT',1) > 0 or 
(Position (JobTitle, "H", 1) > 0 or 
(Position (Organization, "H", 1) > 0 or 
(Position (Street, "H", 1) > 0,1,0) 

Note that you may not have a JobTitle 
field or you may have a Department field. 
Just substitute in this calculation for the fields 
and field names you use. If you don’t use a 
ZIP/City/State lookup table for entering and 
checking City and State fields, you may want 
to expand the calculation to include these 
two as well. 

One difficulty with a calculation like All 
Ret is that finding for a 1 in the All Ret field 
results in a bunch of records (thousands per¬ 
haps) which show problems but with no 
indication of which field or fields carry the 
offending character(s). Thus fixing records is 
less efficient because of the need to search in 
each record to locate the error. The advan¬ 
tage of having a separate equation for each 
field is that it is known after a Find which 
field is questionable. 

Can I retain the advantages of a single 
overall calculation without hiding informa¬ 
tion about which field is in trouble? First I 
tried it for just returns to see if I could make 
the concept work. The result from an If test 
need not be only the numbers one and zero. I 
mentally numbered the fields and then pro¬ 
vided a result that indicated the number(s) of 
the field where the return was detected. I nest¬ 
ed the If functions: 


All Ret = If (Position (FirstName, "U", 1) > 0,1, 

If (Position (LastName, "H", 1) > 0,2, 

If (Position (JobTitle, "11", 1) > 0,3, 

If (Position (Organization, "H", 1) > 0,4, 

If (Position (Street, "U", 1) > 0,5,"")))) 

Sure enough, it works as expected. When 
I tried to use it, however, I found that it was 
not easy (except perhaps with FirstName) to 
make a mental association of a number with a 
field. I quickly realized the obvious answer: 
don’t use numbers. 

It is perfectly acceptable to have text as a 
result of an If test. I tried this: 

All Ret = If (Position (FirstName, "IT, 1) > 0, ”fn". 
If (Position (LastName, "H", 1) > 0, "In", 

If (Position (JobTitle, "IT, 1) > 0, "title". 

If (Position (Organization, "IT, 1) > 0, "org”. 

If (Position (Street, "IT, 1) > 0, "st","")))) 

This approach works fine. When I View 
Index for the All Ret field, I can see the 
names of fields in trouble. If I Find with > 0,1 
get (potentially) multiple fields in multiple 
records. But if I Find with “fn” in the Find 
request, I get just the records that have re¬ 
turns in the FirstName field. A nice built-in 
mnemonic device. 

I abbreviated the text results so that they 
can fit in a small area on the layout. You can 
use longer names - like the real field names - 
if you like. Remember to change the type of 
result from numeric to text in the field defini¬ 
tion of the calculation. 

One more slight difficulty arose. I noticed 
that if I handled the fixes out of sequence, I 
did not get them all. That is, if I first cleared 
all the indicated Street fields of returns, and 
then cleared the FirstName fields, more 
Streets show up in the All Ret calculation. I 
figured out that in nested If functions, a hit 
on a test that appears early in the calculation 
outputs the appropriate result and does not 
even evaluate succeeding nested tests. For an 
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“st” result to show up, all the preceding tests 
need to fall through. This is not a big deal, but 
it does hide from me the magnitude of the 
fixes that need to be made when I am planning 
my time. Is there a way to see all the question¬ 
able fields at once? 

Conventional nested Ifs are used when 
looking for a single result. But I was looking 
for parallel results. I wanted to know not just 
any field in trouble, but all of the fields in 
trouble, at the same time. It occurred to me to 
concatenate the If decisions so that each result 
could appear independent of what came be¬ 
fore it. 

All Ret = If (Position (FirstName, T, 1) > 0, "fnA","") 
& If (Position (LastName, "IT, 1) > 0, "InA","") 

& If (Position (JobTitle, "IT, 1) > 0, "titleA", ”") 

& If (Position (Organization, "11", 1) > 0, "org a", "") 
& If (Position (Street, "IT, 1) > 0, "st", 

This works and really was beginning to 
look good. Notice that I put a space after each 
result, except the last one, so that when there 
are multiple results in a record, a Find can still 
be made for individual fields. I was ready to 
take this basic approach and include in it 
space and period detection as well. While 
working away I realized that I wanted to detect 


not only leading and trailing spaces, but dou¬ 
ble spaces as well. The final result is shown in 
the complete equation below. 

It is handy in some cases to include the 
results of All Ret\Spc\Per in a script. You 
might like to ship the address fields of a 
record out to an external file that contains the 
calculations necessary to automatically re¬ 
place returns, spaces, and periods. A varia¬ 
tion I did not try is to include the return and 
space detection in each of the individual field 
length equations. 

I am now pushing more than a decade of 
maintaining mailing lists in FileMaker. Natu¬ 
rally, my files have evolved substantially. This 
one calculation illustrates how much better a 
solution can get over time. Constant small 
improvements is one of the secrets of product 
quality. The principal applies to FileMaker 
files as well. It is easy to get complacent about 
features which work “OK”. You can even get 
accustomed to a certain mindless routine of 
doing things a hard way. From time to time, 
it is worth remembering that you bought a 
computer, at least in part, to cut down on 
tedium. Don’t give up on a feature until your 
files do most of the work for you. +Ar* 

(© 1996 Elk Horn Publishing, all rights reserved) 


All Ret\Spc\Per = {text result} 

If (Position (FirstName, "11", 1) > 0 or (Position (FirstName,1) > 0 
or Position (FirstName, "aa" ; i ) > o or Left (FirstName, 1) = " A " 
or Right (FirstName, 1) = "A","fnA","") 

& If (Position (LastName, "H", 1) > 0 or (Position (LastName,1) > 0 
or Position (LastName, "aa" ( 1) > 0 or Left (LastName, 1) = "a" 
or Right (LastName, 1) = "a", "| n A","") 

& If (Position (JobTitle, "IT, 1) > 0 or (Position (JobTitle,1) > 0 

or Position (JobTitle, "aa", 1) > 0 or Left (JobTitle, 1) = "a" or Right (JobTitle, 1) = "a", "PosA", 
& If (Position (Organization, "H", 1) > 0 or (Position (Organization,1) > 0 
or Position (Organization, "aa", 1) > 0 or Left (Organization, 1) = "a" 
or Right (Organization, 1) = "a", "OrgA", "") 

& If (Position (Street, "H", 1) > 0 or (Position (Street,1) > 0 or Position (Street, " AA ", 1) > 0 
or Left (Street, 1) = "a" or Right (Street, 1) = "a", "St","") 
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News & Notes 


3.0 For Windows 

Since the last issue, FM Pro 3.0 has become 
available for Windows 3.1. The 32S version 
seems to work pretty well, suffering few of the 
problems of the ClarisWorks 32S based on an 
earlier version of the 32S extension. This 
short circuits a lot of the hand-wringing, 
including in these pages, about whether 3.0 
was worth a forced march into Windows 95. 
Since Windows NT is picking up momen¬ 
tum, PC FileMaker fans can make their oper¬ 
ating system decisions at leisure. 

Server 3.0 v2 

FM Pro Server has been updated to 3.0 v2, 
the first update since the 3.0 release. An up¬ 
dater is available on AOL and the Claris Web 
site, among other places. The updater works 
only on FileMaker Pro Server 3.0 U.S. edi¬ 
tion. It corrects a few minor bugs including 
problems with files recovered in Pro 3.0v3. 

3.0 SDK 

FileMaker Pro 3.0 SDK (Solutions Devel¬ 
opment Kit), including the FM runtime engine, 
has been released. Unlike previous versions, 
this software is not a fully functional File¬ 
Maker application but simply an engine for 
creating runtime applications from File¬ 
Maker files. Runtime databases can be created 
for all platforms supported by FM Pro 3.0. 

The new SDK includes a “Kiosk Mode” 
option which removes menus (including all 
menu items and their keyboard equivalents) 
and access to operating system commands 
(no Quit command is easily available). This 
provides more control over the interface and 
allows better idiot-proofing at the price of 
more attention by developers to details. 


Tango 

EveryWare Development has released 
Tango for FileMaker. Tango provides a 
graphical way (no HTML programming 
required) to create a FileMaker-based dy¬ 
namic Web site. Obvious uses for FileMaker- 
backed Web pages are calendars, reservations 
systems, event registration, catalogs and tele¬ 
phone directories. EveryWare promises a 
steady flow of new features for Tango in the 
next few months. 

CSA 

The new manager of the Claris Solutions 
Alliance (CSA) is Jeff Gagne. Jeff is a Claris 
outsider, coming to sunny Sunnyvale from 
chilly Chicago. Like Heidi Rosen, a sort of 
counterpart at Apple, Jeff has been a client of 
the program he now manages. Matter of fact, 
he has been rather an outspoken critic of 
some aspects of the CSA, although his criti¬ 
cism was always constructive. In particular he 
was concerned about the problem of unqual¬ 
ified CSA members making FileMaker look 
bad. He felt that mediocre work reinforced 
misconceptions that FileMaker was less capa¬ 
ble than other databases. If the Gods punish 
us by giving us what we ask for, Jeff is in for 
an interesting ride. The conflict between the 
public relations and income needs of the CSA 
on the one hand and any attempt to grade 
consultants on the other (“welcome to the 
CSA, you are a C+ consultant...”) has always 
looked to me to be irreconcilable. Still, Jeff's 
letter introducing himself to CSA members 
shows promising tact. If he can pull this off - 
and there’s no question there is a serious 
problem with CSA member credibility - he’ll 
be running Claris in a few years. You heard it 
here first. . 
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